"Rune" <run### [at] mobilixnetdk> wrote in message
news:3be723d9@news.povray.org...
> "Warp" wrote:
> >   But if the user really creates an include file on the fly,
> > then it's treated as any include file which has always existed.
>
> But how is the include file being treated? The same optimized way as the
> main file I hope?
>

I would say, yes, include files would be optomized as well.  I've recently been
thinking about this as well.  That started when I learned that #include'd macros
open the include file each time the macro is called.

A good way is to parse an included file and keep the parsed file in memory for
the entire execution.  When a macro is read it would be parsed into bytecode and
stored in memory.  An index to it would be stored and anytime the macro is
encountered in the following code the bytecode is looked up and executed.  No
need to open the included file again.

> > This method would just be obsolete due to the evaluation
> > function described above.
>
> Yeah, if it allows strings that are several thousands of lines long and
> which can be accesses in all the frames of an animation, then it'd be
> obsolete (I often generate a very large include file on the fly in the first
> frame of an animation and then include it in all the frames).
>

Many interpreters have no theoretical limit on the size of a string.  The
SLang[1] interpreter, for instance, can handle strings hundreds of megabytes in
size.

As for keeping an instance across frames of an animation, this could be handled
with a form of persistent variable.  Also, the parsed bytecode could be stored
between animation frames with no need to re-parse.  Simply re-interpret.  And
since you're just re-interpreting parsed code, which should be very fast, the
need for the large generated include file *might* not be necessary.  It might be
just as fast, or nearly as fast and easier, to generate the data on the fly each
time.  But again, a type of persistent variable could help here.

Michael

[1] SLang is the language that the JED editor is written with.  Well, sort of.
Compiled code performs the core functionality of the editor, but much of that is
being taken over by SLang functionality.  The rest of the functionality of JED
(such as context sensitive actions and language dependant formatting) is handled
strictly through SLang scripts files.  It's at least as fast as any other editor
I've used, and since you can see 98% of the functionality, you can modify it to
suite your tastes.  SLang, by the way, is a parse then interpret language that
can optionally store the bytecode to disk for faster parsing.  See
http://www.s-lang.org/ and http://space.mit.edu/~davis/jed/ for more info.


--
#macro M(D)#local J=strlen(D);#local _=""#while(J>0)#local _=concat(_,substr(D
,J,1))#local J=J-1;#end _#end sphere{z*9,5pigment{rgb x}}#macro N(D,J)text{ttf
"timrom.ttf"M(D)1,0 translate-J}#end#macro O(E,K)#local _=N(E,K)light_source{-
z*9rgb 1projected_through{_}}#end O("leahciM"<1.6,-.3.9>)O("nosnhoJ"<1.6.9.9>)

Post a reply to this message